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Object  Lens:  A  "Spreadsheet"  for  Cooperative  Work 


Abstract 

Object  Lens  allows  unsophisticated  computer  users  to  create  their  own  cooperative  work  applications 
using  a  set  of  simple,  but  powerful,  building  blocks.  By  defining  and  modifying  templates  for  various 
semistructured  objects,  users  can  represent  information  about  people,  tasks,  products,  messages,  and 
many  other  kinds  of  information  in  a  form  that  can  be  processed  intelligently  by  both  people  and  their 
computers.  By  collecting  these  objects  in  customuabU  folders,  users  can  create  their  own  displays  that 
summarize  selected  information  from  the  objects  in  table  or  tree  formats.  Finally,  by  creating 
aemiautonomous  agents,  users  can  specify  rules  for  automatically  processing  this  information  in 
different  ways  at  different  times. 

The  combination  of  these  primitives  provides  a  single  consistent  interface  that  integrates  facilities  for 
object-oriented  databases,  hypertext,  electronic  messaging,  and  rule-based  intelligent  agents.  To 
illustrate  the  power  of  this  combined  approach,  we  describe  several  simple  examples  of  applications 
(such  as  task  tracking,  intelligent  message  routing,  and  database  retrieval)  that  we  have  developed  in 
this  framework. 
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1.  INTRODUCTION 

It  is  common  in  the  computer  industry  today  to  talk  about  the  "next  spreadsheet"~to  claim  that  a 
particular  application  will  be  the  "next  spreadsheet"  or  to  wonder  what  the  "next  spreadsheet"  will  be 
(e.g.,  [Greif,  19881).  Usually  the  term  "spreadsheet"  is  used  in  this  context  simply  to  connote  a  product 
that  embodies  some  kind  of  design  breakthrough  and  is  very  successful. 

We  will  focus  here  on  a  more  specific  property  of  spreadsheet  programs:  They  make  a  restricted,  but 
nevertheless  very  flexible  and  useful,  set  of  computational  capabilities  extremely  easy  to  use.  It  is,  of 
course,  possible  to  do  any  computation  a  spreadsheet  can  do  in  a  general  purpose  programming 
language.  But  because  doing  these  things  with  a  spreadsheet  program  is  so  much  more  convenient, 
the  number  of  people  who  can  use  computers  to  do  them  increases  by  orders  of  magnitude. 

In  this  paper,  we  will  describe  an  early  prototype  of  a  system,  called  Object  Lens,  that  we  believe 
shares  this  property  of  spreadsheets:  It  makes  accessible  to  unsophisticated  computer  users  a  set  of 
computational  and  communications  capabilities  that,  while  limited,  are  quite  flexible  and  useful  for 
supporting  a  wide  variety  of  cooperative  work  activities.  In  other  words,  we  use  the  term 
"spreadsheet"  here,  not  to  connote  financial  modeling  or  constraint  languages,  but  to  connote  a 
flexible  infrastructure  in  which  people  who  are  not  professional  programmers  can  create  or  modify 
their  own  computer  applications. 

In  the  remainder  of  this  paper,  we  will  (1)  describe  the  key  ideas  used  in  the  design  of  Object  Lens,  (2) 
show  how  these  ideas  are  realized  in  Object  Lens  features,  and  (3)  illustrate  the  flexibility  and 
usefulness  of  these  ideas  in  several  examples  of  cooperative  work. 

1.1  Three  views  of  Object  Lens 

Before  proceeding,  it  is  useful  to  point  out  three  ways  of  viewing  the  Object  Lens  system: 


(1)  Object  Lens  is  the  "second  generation"  of  the  Information  Lens  system.  Object  Lens  is  based  on  our 
experience  with  using  arid  enhancing  the  InTormation  Lens  (Malone,  Grant,  Turbak,  Brobst  &  Cohen, 
1987;  Malone,  Grant,  Lai,  Rao,  &  Rosenblitt,  1987),  an  intelligent  system  for  information  sharing  and 
coordination.  A  ver>-  large  number  of  the  enhancements  that  we  and  others  have  suggested  for  the 
Information  Lens  are  included  in  Object  Lens.  Like  the  Information  Lens,  Object  Lens  uses  ideas  from 
artificial  intelligence  and  user  interface  design  to  represent  knowledge  in  such  a  way  that  both  people 
and  their  computational  agents  can  process  it  intelligently.  Object  Lens,  however,  is  a  significant 
generalization  of  the  Information  Lens.  It  potentially  goes  far  beyond  the  Information  Lens  in  the 
kinds  of  knowledge  that  can  be  represented  and  the  ways  that  information  can  be  manipulated. 

(2)  Object  Lens  is  a  user  interface  that  integrates  hypertext,  object-oriented  databases,  electronic 
messaging,  and  rule-based  intelligent  agents.  Object  Lens  does  not  include  all  the  capabilities  of  all 
these  difTerent  classes  of  systems,  but  we  have  been  surprised  at  how  cleanly  a  large  portion  of  these 
diverse  capabilities  can  be  integrated.  The  key  contribution  of  Object  Lens  is  thus  not  the 
completeness  of  its  implementation,  but  the  integration  of  its  user  interface.  Since  the  capabilities  of 
these  diiTerent  kinds  of  systems  are  no  longer  separate  applications,  each  capability  is  more  useful 
than  it  would  be  alone,  and  the  resulting  system  is  unusually  flexible. 

(3)  Object  Lens  is  a  knowledge-bated  environment  for  developing  cooperative  work  applications.  In  the 
original  Information  Lens  system,  we  developed  specific  applications  for  information  sharing,  meeting 
scheduling,  project  management,  and  computer  conferencing.  From  the  viewpoint  of  knowledge-based 
systems,  these  applications  only  included  knowledge  about  different  types  of  messages:  the  kinds  of 
information  the  messages  contained  and  the  kinds  of  actions  they  could  evoke.  Object  Lens,  in 
contrast,  can  include  explicit  knowledge  about  many  other  kinds  of  objects,  such  as  people,  tasks, 
meetings,  products,  and  companies.  We  expect  that  the  flexible  tools  Object  Lens  provides  for  dealing 
with  these  diverse  kinds  of  knowledge  will  significantly  increase  the  ease  of  developing  a  much  wider 
range  of  applications.  This  last  view  of  Object  Lens,  which  emphasizes  its  flexibility,  is  our  primary 
focus  in  this  paper. 


2.  KEY  IDEAS 

One  of  the  most  important  characteristics  of  Object  Lens  is  that  it  is  a  semiformal  system.  We  define  a 
semiformal  system  as  a  computer  system  that  has  the  following  three  properties:  (1)  it  represents  and 
automatically  processes  certain  information  in  formally  specified  ways;  (2)  it  represents  and  makes  it 
easy  for  humans  to  process  the  same  or  other  information  in  ways  that  are  not  formally  Sf)ecified;  and 
(3)  it  allows  the  boundary  between  formal  processing  by  computers  and  informal  processing  by  people 
to  be  easily  changed. 

Semiformal  systems  are  most  useful  when  we  understand  enough  to  formalize  in  a  computer  system 
some,  but  not  all,  of  the  knowledge  relevant  to  acting  in  a  given  situation.  Such  systems  are  often 
useful  in  supporting  individual  work,  and  we  believe  they  are  especially  important  in  supporting 
cooperative  work  where  there  are  usually  some  well-understood  patterns  in  people's  behavior,  but 
where  there  is  usually  also  a  very  large  amount  of  other  knowledge  that  is  potentially  relevant  but 
difficult  to  specify. 

In  order  to  create  such  a  flexible  semiformal  system,  the  knowledge  embodied  in  the  system  must  be 
exposed  to  users  in  a  way  that  is  both  visible  aj\d  changeabU  (cf,  Turbak,  1986).  That  is,  users  must  be 
able  to  easily  see  and  change  the  information  and  the  processing  rules  included  in  the  system.  In 
Object  Lens,  there  are  three  key  ideas  about  how  to  represent  and  expose  knowledge  to  users: 

(1)  "Passive"  information  is  represented  in  semistructured  objects  with  template-based 
interfaces; 

(2)  "Aggregate"  information  from  collections  of  objects  is  summarized  in  customizable  folders; 
and 

(2)  "Active"  rules  for  processing  information  are  represented  in  semiautonomous  agents. 


In  the  remainder  of  section  2,  we  will  provide  an  overview  of  how  these  two  components  allow  us  to 
expose  knowledge  to  users  in  a  way  that  is  both  visible  and  changeable.  Detailed  descriptions  of  the 
system  features  are  in  section  3. 

2.1  Semistructured  objects 

Users  of  the  Object  Lens  system  can  create,  modify,  retrieve,  and  display  objects  that  represent  many 
physically  or  conceptually  familiar  things  such  as  messages,  p>eople,  meetings,  tasks,  manufactured 
parts,  and  software  bugs.  The  system  provides  an  interface  to  an  object-oriented  database  in  the  sense 
that  (1)  each  object  includes  a  collection  of  fields  arnl  field  values,  (2)  each  object  type  has  a  set  of 
actions  that  can  be  performed  upon  it,  and  (3)  the  objects  are  arranged  in  a  hierarchy  of  increasingly 
specialized  types  with  each  object  type  "inheriting"  fields,  actions,  and  other  properties  from  its 
"parents"  (see  Dittrich  &  Dayal,  1986,  Shriver  &  Wegner,  1987,  Stefik  &  Bobrow,  1986).  For  example, 
a  TASK  object  may  have  fields  like  Requestor,  Performer,  Descnption,  and  Deadline;  a  PERSON  object 
may  have  fields  like  Name,  Phone,  Address,  and  Job  title;  and  a  STUDENT  object  may  add  fields  like 
Year  and  Advisor  to  the  fields  present  in  all  PERSON  objects.  Some  objects  (e.g.,  MESSAGES)  have 
specialized  actions  defined  for  them  (eg  ,  Answer  and  Forward).  As  described  in  more  detail  below,  we 
have  provided  rudimentary  facilities  for  saving  and  sharing  objects,  and  we  are  currently  exploring 
ways  to  link  our  interface  to  remote  databases. 

The  objects  in  Object  Lens,  like  messages  in  the  Information  Lens,  are  semistructured  in  the  sense  that 
users  can  fill  in  as  much  or  as  little  information  in  different  fields  as  they  desire  and  the  information  in 
a  field  is  not  necessarily  of  any  specific  type  (e  g  ,  it  may  be  free  text,  such  as  "I  don't  know"). 

2.1.1  Template -based  user  interfaces.  Users  can  see  and  change  objects  through  a  particularly 
natural  form  of  template-based  user  interface.  These  interfaces  have  a  number  of  virtues.  For 
instance:  (1)  they  resemble  forms,  with  which  users  are  already  familiar,  (2)  they  conveniently  inform 
users  about  the  fields  contained  in  an  object  and  about  other  iiiformation  such  as  the  likely 
alternatives  for  different  fields,  and  (3)  their  use  is  consistent  across  many  different  kinds  of  objects. 


We  will  see  below  how  this  interface  approach,  which  was  used  for  messages  and  rules  in  the 
Information  Lens,  can  be  easily  generalized  to  many  different  kinds  of  objects. 

2.1.2  Relationships  among  objects.  Users  can  easily  see  and  change  the  relationships  among 
objects  by  inserting  and  deleting  links  between  the  objects.  For  instance,  the  Requestor  and  Performer 
fields  of  a  Task  object  might  contain  links  to  the  Person  objects  that  represent,  respectively,  the  person 
who  requested  that  the  task  be  done  and  the  person  who  will  perform  the  task.  Then,  for  instance, 
when  the  user  looks  at  the  Task  object,  it  will  be  easy  to  get  more  information  (e.g.,  the  phone 
numbers)  about  the  people  involved  with  the  task.  We  will  see  below  how  this  capability  of  linking 
objects  to  each  other  provides  a  rudimentary  hypertext  system  as  a  special  case  (see  Conklin,  1987,  for 
an  extensive  review  of  hypertext  systems).  We  will  see  below  how  it  is  also  possible  for  an  object  to 
which  a  link  appears  to  be  displayed  as  an  embedded  template  inside  the  original  template. 

2.1.3  Tailorable  display  formats.  Users  have  several  options  for  changing  the  ways  they  see 
objects.  For  instance,  they  can  easily:  (1)  select  which  fields  will  be  shown  and  which  will  be 
suppressed,  (2)  rename  selected  fields,  and  (3)  specify  the  default  and  alternative  values  the  system 
presents  for  individual  fields. 

2.1.4  Inheritance  hierarchy  for  objects.  The  creation  and  modification  of  type  definitions  is 
simplified  by  arranging  object  types  in  an  inheritance  hierarchy  (e.g.,  Stefik  &  Bobrow,  1986).  New 
types  of  objects  are  defined  as  specializations  of  existing  object  types,  and  they  automatically  "inherit" 
all  properties  of  the  existing  objects  except  those  which  are  specifically  "overridden."  Since  most  of  the 
information  about  new  object  types  can  thus  be  "inherited"  from  existing  types,  rather  than  having  to 
be  re-entered  each  time,  creating  new  object  types  becomes  simpler.  Also,  when  an  object  type 
definition  is  changed  later,  the  changes  are  automatically  "inherited"  by  the  specializations  of  that 
object  type. 


2.2  Customiiable  folders 

Users  of  Object  Lens  can  group  collections  of  objects  together  into  special  kinds  of  objects  called 
Folders.  For  instance,  folders  can  be  created  for  groups  of  people  (e.g..  project  teams,  company 
directory),  tasks  (eg,  those  completed,  those  to  be  done  by  you,  those  to  be  done  by  others),  messages 
(group>ed  according  to  topic  or  urgency),  and  so  forth.  Users  can  also  easily  customize  their  own 
displays  to  summarize  the  contents  of  objects  in  a  folder.  For  instance,  they  can  select  certain  fields  to 
be  displayed  in  a  table  with  each  row  representing  an  object  in  the  folder  and  each  column 
representing  a  field.  They  can  also  select  fields  from  which  the  links  between  objects  will  be  used  to 
create  a  tree  (or  graph)  display  with  each  object  represented  as  a  node  in  the  tree  and  each  link  in  the 
selected  field  represented  as  a  line  between  nodes. 

2.3  Semiautonomous  agents 

Users  of  the  Object  Lens  system  can  create  rule-based  "agents"  that  process  information  automatically 
on  behalf  of  their  users  (see  Crowston  &  Malone,  1988,  for  an  extended  discussion  of  agents).  These 
agents  provide  a  natural  way  of  partitioning  the  tasks  performed  automatically  by  the  system.  As  we 
will  see  below,  agents  can  be  "triggered"  by  events  such  as  the  Eurrival  of  new  mail,  the  appearance  of  a 
new  object  in  a  specified  folder,  the  arrival  of  a  pre-specified  time,  or  an  explicit  selection  by  the  user. 
When  an  agent  is  triggered  it  applies  a  set  of  rules  to  a  specified  collection  of  objects.  If  an  object 
satisfies  the  criteria  specified  in  a  rule,  the  rule  p>€rforms  some  prespecified  action.  These  actions  can 
be  general  actions  such  as  retrieving,  classifying,  mailing,  and  deleting  objects  or  object-specific 
actions  such  as  loading  files  or  adding  events  to  a  calendar. 

The  agents  in  Object  Lens  are  "autonomous"  in  the  sense  that  once  they  have  been  created,  they  can 
take  actions  without  the  explicit  attention  of  a  human  user.  They  are  only  "semiautonomous," 
however,  in  the  sense  that  (a)  they  are  always  controlled  by  a  human  user  (that  is,  all  their  rules  can 
be  easily  seen  and  changed  by  their  human  user),  and  (b)  they  may  oflen  "refer"  objects  to  their  human 
user  for  action  (e.g.,  by  leaving  the  object  in  the  user's  inbox)  rather  than  taking  any  actions  on  their 
own. 


2.3.1  Descriptions.  Since  agents  and  rules  are  themselves  objects,  users  can  see  and  modify 
them  with  the  same  template-based  user  interface  that  is  used  for  all  other  kinds  of  objects.  To  specify 
the  criteria  for  when  a  rule  should  act  upon  a  given  object,  users  create  descriptions  of  the  objects  to 
which  the  rules  apply.  A  description  is  simply  a  partially  filled-in  template  for  an  object  of  a  particular 
type.  Descriptions  can  also  include  embedded  descriptions  that  specify  characteristics  that  must  be 
satisfied  by  objects  to  which  the  original  object  is  linked.  For  instance,  a  description  of  a  Task  might 
include  an  embedded  description  of  the  Person  who  will  perform  the  task.  These  embedded 
descriptions  (like  those  in  the  Rabbit  system  [Tou  et  al,  1982]),  allow  users  to  easily  specify  object 
retrieval  operations  that  are  equivalent  to  "joins"  followed  by  "selects"  in  a  relational  database. 

3.  SYSTEM  FEATURES 

In  this  section,  we  will  describe  in  more  detail  the  basic  system  features  of  Object  Lens  and  illustrate 
them  with  simple  examples  (see  Lai  [1987]  for  more  details  about  an  earlier  version  of  the  system). 
The  Object  Lens  system  is  implemented  in  Interlisp-D  on  Xerox  1100  series  workstations  connected  by 
an  Ethernet.  The  system  makes  heavy  use  of  the  object-oriented  programming  environment  provided 
by  Loops  and  the  built-in  text  editor,  Tedit.  Except  where  otherwise  noted,  everything  described  here 
has  been  implemented,  but  many  features  have  not  yet  been  extensively  tested.  As  of  this  writing,  the 
basic  mail  handling  capabilities  have  been  used  regularly  by  two  people  in  our  development  group  for 
about  6  months  and  the  other  facilities  have  received  limited  testing. 

3.0.1  Terminology:  Objects  and  templates.  Before  proceeding  it  is  helpful  to  clarify  some 
terminology  concerning  objects  and  templates.  First,  we  distinguish  between  object  types  (or  "classes") 
and  specific  object  instances  (e.g.,  see  Fikes  &  Kehler,  1985).  We  use  the  term  object  type  to  refer  to  a 
kind  of  object  (such  as  Person  or  Task)  and  the  term  object  instance  (or  simply  "instance")  to  refer  to  a 
specific  example  of  one  of  these  object  types  (eg.,  "Joe  Smith  or  "Task  No.  17").  In  contexts  where  the 
distinction  between  object  types  and  object  instances  is  not  critical,  we  use  the  term  objects  to  include 
both. 


8 

We  also  use  the  term  template  in  two  ways  First,  in  a  general  sense,  we  use  the  term  template  to  mean 
any  semi-structured  collection  of  fields  and  field  contents.  Most  of  a  user's  interactions  with  Object 
Lens  are  based  on  such  templates.  Second,  in  the  Object  Lens  screen  displays,  we  use  the  word 
Template  to  mean  object  type  definition.  (When  we  use  Template  in  this  specialized  sense,  we  will 
always  capitalize  it.)  For  instance,  users  can  change  the  display  format  for  all  Person  objects  by 
editing  the  Template  that  defines  the  Person  object  type. 

3.1  Editing  instances 

Figure  1  shows  a  template  for  an  instance  of  a  Person.  Using  the  built-in  text  editor,  users  can  insert 
text  or  bitmaps  in  any  field.  In  addition,  when  users  click  on  a  field  name  with  the  mouse,  a  list  of 
likely  alternative  values  for  that  field  appears  in  a  pwp-up  menu.  The  alternatives  may  be  links  to 
other  objects  or  just  text  strings.  Selecting  one  of  these  alternatives  causes  the  alternative  to  be 
automatically  inserted  in  the  field.  For  instance,  the  figure  contains  a  link  to  the  Person  object 
representing  Kum-Yew  Lai's  supervisor.  To  insert  links  to  objects  that  are  not  in  the  alternatives  list, 
the  user  (a)  positions  the  cursor  at  the  place  in  the  template  where  the  link  is  to  be  inserted,  (b)  selects 
the  Add  Link  option  from  the  menu  at  the  top  of  the  window,  and  then  (c)  points  to  the  object  to  which 
the  link  should  be  made.  After  a  link  is  inserted,  clicking  on  it  with  the  mouse  causes  the  object  it 
points  to  to  appear  on  the  screen. 

In  the  current  version  of  Object  Lens,  users  can  insert  any  combination  of  text,  numbers,  links,  and 
bitmaps  in  any  field.  Then,  in  some  cases,  type  checking  is  done  when  the  editing  window  for  the 
instance  is  closed  or  when  certain  kinds  of  processing  are  done.  For  instance,  the  To  and  cc  fields  are 
checked  for  valid  addresses  before  sending  messages  and  the  "move  to"  field  in  rule  actions  is  checked 
for  valid  folders  (see  below  for  descriptions  of  rules  and  folders).  In  future  versions  of  Object  Lens,  we 
may  experiment  with  more  restrictive  t>'pe  enforcement  in  certain  fields.  For  instance,  it  should 
probably  be  impossible  to  even  insert  something  other  than  a  folder  in  the  "move  to"  field  of  a  rule 
action. 


Figure  2  shows  a  slightly  more  complex  template;  this  one  is  for  a  Bug  Fix  Request  message.  One  of  the 
fields  of  this  template  is  the  Bug  to  be  fixed  and  the  value  of  this  field  is  a  link  to  a  Bug  object.  In  this 
case,  instead  of  simply  showing  a  link  to  the  Bug  object,  the  template  contains  an  embedded  template 
for  the  Bug  object  itself.  The  fields  in  this  embedded  template  can  be  edited  just  like  the  rest  of  the 
fields  in  the  template.  We  will  see  below  how  users  can  specify  whether  links  to  other  objects  should  be 
displayed  as  link  icons  (as  in  Figure  1)  or  as  embedded  templates  (as  in  Figure  2). 

3.2  Creating  new  Instances 

To  create  and  display  a  new  instance  of  an  object  type  that  already  exists,  users  click  with  the  mouse 
on  the  definition  (i.e.,  the  Template)  for  that  object  type.  Figure  3  shows  the  Templates  currently 
included  in  our  system.  For  instance,  to  send  a  new  message,  users  click  on  the  Template  for  the  type 
of  message  they  wauit  to  create;  to  create  a  new  person  object,  users  click  on  the  Person  Template. 
Then  an  object  instance,  like  those  shown  in  Figures  1  and  2,  will  appear  and  the  user  can  fill  it  in. 

3.3  Creating  new  object  types 

To  create  a  new  object  type,  users  click  (with  the  middle  mouse  button,  instead  of  the  lefl  one)  on  the 
Template  for  the  "parent"  object  type  (see  Figure  3).  This  causes  a  menu  to  appear  showing 
alternative  actions  that  can  be  performed  on  a  Template.  One  of  these  actions  is  to  Create  a 
subtemplate.  When  the  user  selects  this  action,  a  new  Template  is  created  with  all  the  fields  and 
properties  of  its  "parent."  Then  users  can  add  fields  to  the  new  Template  or  change  its  display  format 
and  other  properties  (see  below). 

In  the  current  version  of  Object  Lens,  all  Things  have  three  fields:  Name,  Keywords,  and  Comments. 
All  objects  inherit  these  fields,  though  as  discussed  below,  some  objects  rename  these  fields  or  suppress 
their  display.  For  instance.  Messages  rename  the  Name  field  to  be  Subject  and  the  Comments  field  to 
be  Text. 
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3.4  Changing  the  display  format  and  other  properties  of  object  types 

To  change  the  display  format  or  other  properties  of  an  object  type,  users  "edit"  the  Template  that 
defines  the  object  t>'pe.  Users  make  these  changes  by  selecting  actions  from  the  menu  that  appears 
when  they  click  on  the  Template  (as  shown  in  Figure  3)  with  both  mouse  buttons.  In  this  way,  users 
can  change  (a)  which  fields  of  the  object  are  actually  displayed,  (b)  the  names  of  the  fields  that  are 
displayed,  (c)  the  alternative  values  that  are  displayed  for  each  field,  (d)  the  default  values  that  are 
displayed  in  each  field  when  new  instances  are  created,  and  (e)  whether  the  links  in  a  field  should  be 
shown  as  link  icons  (see  Figure  1)  or  as  embedded  templates  (see  Figure  2).  In  this  mode,  users  can 
also  add  or  delete  fields  from  a  template.  All  the  changes  made  to  a  template  are  applied  to  old 
instances  of  an  object  type  as  well  as  to  newly  created  ones.  For  example,  if  the  user  changes  the  name 
of  a  field,  then  the  new  name  will  be  shown  when  any  old  instances  are  redisplayed. 

We  anticipate  that  this  system  will  be  used  with  a  core  set  of  object  types  shared  by  the  users  in  a 
group  and  that  the  fields  in  these  tj-pes  will  be  modified  only  by  an  "authorized  view  administrator." 
Other  users  will  be  able  to  change  the  display  format  of  these  types  (eg.,  suppress  the  display  of  a  field 
or  change  its  name),  but  they  would  not  be  able  to  delete  or  add  fields  to  these  "official"  types.  All 
users  would,  however,  be  able  to  create  their  own  types  as  specializations  of  the  official  types,  and  for 
these  types  they  could  add  and  delete  new  fields  as  desired.  Elsewhere  (Lee  &  Malone,  1988a,  1988b) 
we  have  proposed  a  scheme  for  letting  an  arbitrarily  large  number  of  groups  share  p>artially 
overlapping  sets  of  type  definitions  in  arbitrary  ways.  One  of  the  key  ideas  of  this  scheme  is  that 
specialized  types  created  by  one  group  can  be  interpreted  by  members  of  another  group  as  instances  of 
the  most  specific  "ancestor"  type  that  both  groups  share.  For  instance,  a  "Student"  object  created  by 
one  group  might  be  interpreted  as  a  "Person"  object  by  another  group  that  does  not  have  a  definition 
for  "Student." 

3.5  Folders 

As  noted  above.  Object  Lens  users  can  group  collections  of  objects  together  into  sp>ecial  kinds  of  objects 
called  Folders  (see  Figure  7).  An  object  can  be  added  to  a  folder  in  two  ways:   (1)  automatically,  as  the 
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result  of  a  rule  action,  or  (2)  manually  using  the  Add  Link  action  from  the  "Others*  submenu  on  the 
folder.  In  both  cases,  the  folders  will  contain  links  to  the  objects,  not  the  objects  themselves. 
Therefore,  the  same  object  can  appear  in  more  than  one  folder.  Other  actions  for  moving,  copying,  and 
deleting  both  objects  and  links  are  described  below. 

Object  Lens  currently  provides  two  formats  for  displaying  the  contents  of  folders:  tables  and  trees. 
Tables  show  the  values  of  selected  fields  from  the  objects  contained  in  the  folder.  For  instance,  Figure 
7a  shows  a  folder  that  contains  objects  representing  people  with  the  fields  displayed  for  a  simple  office 
directory.  Users  can  easily  tailor  the  format  of  these  displays  by  selecting  from  a  menu  the  fields  they 
want  to  have  included  in  the  table.  For  instance,  Figxire  7b  shows  the  same  folder,  but  with  the  display 
format  changed  to  include  a  difTerent  set  of  fields. 

Trees  are  graphs  that  show  the  objects  in  a  folder  and  the  links  that  connect  these  objects.  Just  as 
users  can  select  the  fields  to  be  shown  in  a  table,  they  can  also  select  the  fields  from  which  liiJis  will  be 
shown.  For  instance.  Figure  7c  shows  the  same  folder  again,  but  this  time  in.  tree  format  with  the 
"Supervisor"  field  selected  as  the  one  from  which  links  are  displayed.  In  this  case,  the  display 
resembles  a  simple  orgarvization  chart.  In  the  current  version  of  Object  Lens,  only  the  links  in  one 
field  at  a  time  can  be  displayed  in  a  tree.  In  future  versions,  we  plan  to  allow  links  from  multiple  fields 
to  be  shown  with  the  links  from  different  fields  being  displayed  as  different  types  of  lines  (e.g.,  solid, 
dotted,  etc.). 

When  a  new  folder  is  created,  the  user  is  asked  to  select  the  default  object  type  to  be  contained  in  the 
folder.  The  user  is  then  allowed  to  choose  from  the  fields  of  this  default  object  type  when  selecting  the 
fields  to  show  in  a  table  or  when  selecting  the  fields  from  which  links  will  be  shown  in  a  tree.  Even 
though  all  folders  have  default  object  types,  no  strict  type  checking  is  enforced.  If  an  object  of  an 
unexpected  type  is  inserted  into  a  folder,  only  the  fields  it  shares  with  the  default  type  are  displayed  in 
tables  and  trees. 
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3.8  Performing  actions  on  objects 

In  addition  to  editing  the  contents  of  objects,  users  can  also  perform  pre-defined  actions  on  them.  The 
actions  that  can  be  performed  at  any  time  depend  on  two  primary  factors:  (1)  the  type  of  object  being 
acted  upon,  and  (2)  the  context  in  which  the  action  is  invoked. 

3  6  1  Object  specific  actions  Each  object  type  has  a  set  of  actions  that  can  be  performed  on  it. 
Some  of  these  actions  are  "inherited"  directly  from  the  "parents"  of  the  object  type.  Others  may  be 
modified  or  added  specLHcally  for  this  object  type.  For  instance,  there  are  some  actions,  such  as 
Hardcopy  and  Save  that  can  be  performed  on  all  objects  (i.e.,  all  instances  of  Thing  and  all  its 
subtypes).  (Some  of  these  actions,  such  as  Hardcopy,  are  not  yet  implemented  for  all  object  types.)  In 
addition,  more  specialized  types  of  objects  have  other  actions  defined  for  them.  For  instance,  agents 
have  a  Run  action  that  triggers  them  to  start  running,  and  folders  have  a  Change  Display  Format 
action  that  changes  them  from  table  format  to  tree  format  or  vice  versa. 

In  a  few  cases,  the  object  specific  actions  depend,  not  just  on  the  type  of  the  object,  but  also  on  its  state. 
For  instance,  messages  created  on  the  local  workstation  have  a  Send  action,  and  messages  received 
from  elsewhere  have  actions  such  as  Answer  and  Forward.  So  far  these  state-specific  actions  on  objects 
are  implemented  as  special  cases.  However,  we  would  like  to  experiment  with  a  more  general 
mechanism  for  representing  state-specific  actions  and  perhaps  making  this  representation  accessible 
to  users.  In  some  ways,  this  mechanism  would  be  a  generalization  of  the  conversation  manager  in  the 
Coordinator  CN^-'inograd,  19S8)  which  restricts  the  types  of  messages  that  a  user  can  send  at  a  given 
point  in  a  conversation,  based  on  the  conversation  state. 

3.6.2  Context  specific  actions.  There  are  some  actions  that  can  be  applied  to  any  kind  of  object, 
but  which  can  be  invoked  only  from  certain  contexts.  The  primary  contexts  are;  (1)  from  an  editor 
(like  the  one  in  Figure  1),  (2)  from  a  folder  that  contains  the  object,  (3)  from  a  rule  operating  on  the 
object,  and  (4)  from  a  link  icon  for  the  object. 
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For  instance,  when  an  object  is  being  displayed  in  an  editor,  there  are  several  kinds  of  actions,  such  as 
Close,  Move,  and  Shape,  that  apply  to  the  editing  vrindow.  Other  actions  in  an  editor  include:  (a)  Add 
Link,  (insert  at  the  current  cursor  position  a  link  to  another  object  selected  by  the  user),  and  (b)  Cancel 
(close  the  window  without  saving  any  of  the  changes  made  since  the  window  was  last  opened). 

When  an  object  is  displayed  in  a  folder,  other  context-specific  actions  can  be  applied  to  it,  such  as:  (a) 
Show  (open  an  editor  on  the  object),  and  (b)  Select  (select  the  item  for  some  later  folder  action  such  as 
Delete  Selection). 

The  actions  that  can  be  applied  to  an  object  by  rules  are  discussed  in  Section  3.7  below.  The  actions 
that  can  be  applied  to  link  icons  include:  Show  (open  an  editor  on  the  object),  and  Delete  (delete  this 
link  to  the  object). 

3.6.3  Displaying  and  invoking  actions.  Users  invoke  the  above  actions  in  slightly  different 
ways  depending  on  the  context  in  which  the  object  is  displayed.  If  the  object  is  displayed  in  an  editor 
(like  the  one  in  Figure  1),  then  several  of  its  most  common  actions  are  shown  across  the  top  of  the 
editor,  and  all  the  other  actions  are  shown  in  a  menu  that  pops  up  when  the  "Others*  action  is 
selected. 

When  a  link  to  an  object  is  displayed  (either  as  a  link  icon  or  as  a  row  in  a  table),  users  can  invoke 
actions  in  two  ways.  First,  if  users  click  on  the  link  with  the  middle  mouse  button,  a  menu  pops  up 
showing  all  possible  actions  on  the  object.  In  addition,  simply  clicking  on  the  link  with  the  left  mouse 
button  invokes  the  most  common  action.  For  instance,  clicking  with  the  left  button  on  a  row  in  a  table 
Selects  the  object  for  subsequent  folder  actions,  while  clicking  with  the  lefl  button  on  a  link  icon  inside 
an  editor  Shows  the  object  in  another  window  on  the  screen. 

3.7  Creating  agents  and  rules 

In  some  cases,  agents  can  take  actions  automatically  on  behalf  of  their  users.  For  instance.  Figure  4 
shows  an  example  of  a  simple  agent  designed  to  help  a  user  process  incoming  mail.  When  an  agent  is 
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triggered,  it  applies  a  set  of  rules  to  a  collection  of  objects  in  a  folder.  The  agent  in  Figure  4  is  applied 
to  objects  in  the  New  Mail  folder  and  is  triggered  by  the  arrival  of  new  mail.  That  is,  when  mail  is 
retrieved  to  the  workstation,  the  mail  program  automatically  inserts  links  to  the  new  messages  into 
the  user's  New  Mail  folder  and  these  New  Links  trigger  the  agent.  In  the  current  version  of  Object 
Lens,  two  other  kinds  of  automatic  triggers  are  available:  Daily  at  Midnight,  and  On  the  Hour. 

The  agent  shown  in  Figure  4  includes  several  rules,  one  of  which  is  shown  in  Figure  5  A  rule  contains 
an  "IF"  field  (predicate)  and  a  'THEN"  field  (action).  Both  these  parts  of  the  rule  contain  links  to  other 
objects  which  are  shown  as  embedded  templates.  The  IF  part  of  the  rule  is  a  description,  a  sp>ecial  kind 
of  template  that  describes  a  set  of  instances  in  terms  of  the  valuesof  their  fields.  The  THEN  part  of  the 
rule  is  an.  Action  object. 

To  construct  the  IF  part  of  a  rule,  a  user  (a)  clicks  on  the  IF  field  with  the  middle  mouse  button,  (b) 
selects  "Descriptions"  from  the  menu  presented,  and  then  (c)  selects  an  object  type  from  the  tree  of 
object  types  presented.  This  causes  a  description  of  the  appropriate  type  to  be  inserted  in  the  rule  as  an 
embedded  template,  and  the  user  can  then  fill  in  the  fields  in  this  description  to  specify  the  values  that 
must  appear  in  particular  fields  for  an  object  to  satisfy  the  rule.  As  in  the  Information  Lens,  more 
complex  specifications  for  a  field  can  be  constructed  by  combining  strings  with  and,  or,  not,  and 
parentheses  (i.e.,  arbitrary  Boolean  combinations  are  possible  within  a  field).  If  specifications  appear 
in  more  than  one  field,  then  all  specifications  must  be  satisfied  at  once  for  the  rule  to  succeed  (i.e., 
specifications  in  diiTerent  fields  are  implicitly  and-ed).  As  in  the  other  template-based  editors  in 
Object  Lens,  pop-up  menus  listing  likely  alternatives  for  a  field  are  available  in  editing  descriptions. 

To  sj>ecify  the  THEN  part  of  a  rule,  a  user  simply  clicks  on  the  THEN  field  and  selects  an  action  from 
the  menu  of  alternatives  presented.  These  actions  are  applied  to  the  "current  object"  (the  object 
matched  by  the  IF  part  of  the  rule)  in  the  context  of  the  "current  folder"  (the  folder  specified  in  the 
"Apply  to"  field  of  the  agent).  In  some  cases  (such  as  the  "Move"  action  shown  here),  the  user  also 
needs  to  fill  in  some  fields  in  the  embedded  template  for  the  action  (e.g.,  the  field  sf>ecifying  where  the 
object  is  to  be  moved).  The  actions  currently  implemented  in  rules  include  the  following:  "copy"  (add 
the  current  object  to  a  dLfTerent  folder  without  removing  it  from  the  current  folder),  "move"  (add  the 


15 

current  object  to  a  difTerent  folder  and  delete  it  from  the  current  folder),  "delete"  (remove  the  object 
from  the  current  folder),  and  "add  keyword"  (add  the  specified  keyword  to  the  Keywords  field  of  the 
object).  In  addition,  rules  can  invoke  object  specific  actions,  including  the  actions  that  apply  to  all 
objects  such  as  "hardcopy"  and  "save".  We  view  the  addition  of  more  rule  actions  (and  possibly  the 
refinement  of  the  rule  syntax)  as  one  of  the  important  directions  for  our  ongoing  research. 

The  rules  are  applied  in  the  order  in  which  they  appear  in  the  agent's  rule  folder.  Users  can  create 
extended  reasoning  chains  by  having  some  rules  set  characteristics  of  objects  (using  the  Add  Keyword 
action)  which  other  rules  test  (by  checking  the  Keyword  field). 

3.7.1  Embedded  descriptions.  With  the  capabilities  we  have  described  so  far,  all  rules  must 
depend  only  on  information  contained  in  the  objects  to  which  they  are  being  applied.  For  instance,  a 
rule  about  a  message  can  depend  only  on  information  contained  in  the  message  itself.  It  is  often 
desirable,  however,  to  be  able  to  specify  rules  that  also  depend  on  other  information  contained 
elsewhere  in  the  knowledge  base.  For  instance,  in  the  Information  Lens  system,  if  a  user  wanted  to 
specify  a  rule  that  applied  to  all  messages  from  vice  presidents,  the  rule  would  have  to  include  in  the 
From  field,  the  names  of  all  the  vice  presidents. 

In  Object  Lens,  it  is  possible  to  draw  upon  other  information  by  having  descriptions  embedded  within 
other  descriptions.  For  instance,  the  rule  shown  in  Figure  6  will  be  satisfied  if  the  message  is  from  any 
person  with  a  job  title  that  includes  "vice  president".  To  apply  this  rule,  the  system  checks  to  see 
whether  the  string  in  the  From  field  of  the  message  is  the  same  as  the  Name  of  any  Person  object  in  the 
knowledge  base  that  satisfies  the  description. 

3.8  Navigating  through  the  system 

The  starting  point  for  navigation  through  the  Object  Lens  system  is  the  Object  Lens  Icon,  a  window 
that  shows  whether  the  user  has  new  mail  waiting  and  includes  a  menu  item  to  Show  Basics  (show  the 
basic  folders  included  in  the  system).  The  system  folders  accessible  through  the  Show  Basics  action 
include:    (1)  a  folder  containing  all  the  other  folders  in  the  system,  (2)  a  folder  containing  all  the 
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Templates  defined  in  the  system  (Figure  3),  (3)  a  folder  containing  all  the  agents  defined  in  the  system, 
(4)  a  folder  for  each  object  t>-p€  containing  all  the  instances  of  that  t>-pe  in  the  system,  and  (5)  the  New 
Mail  folder,  into  which  new  mail  retrieved  from  the  mail  server  is  automatically  inserted.  In  addition, 
we  have  designed  but  not  fully  implemented  two  other  folders:  (6)  Everything,  a  virtual  folder 
containing  all  objects  in  the  system.,  and  (7)  Orphans,  a  virtual  folder  containing  all  objects  to  which  no 
links  exist. 

These  basic  folders  provide  users  with  convenient  starting  pwints  for  locating  any  object  in  the  system. 
In  relatively  small  systems,  users  can  browse  through  these  folders  directly.  In  larger  systems,  we 
expect  that  users  will  let  their  agents  search  through  the  system  folders  to  find  objects  that  meet 
certain  criteria.  It  is  also  possible  for  (a)  individual  users  to  create  their  own  customised  "directory" 
folders  that  contain  the  folders  and  other  objects  they  most  often  use,  and  (b)  application  developers  to 
create  folders  containing  the  objects  used  in  their  application. 

3.9  Saving  and  sharing  knowledge 

One  of  the  important  research  directions  we  plan  to  pursue  in  the  Object  Lens  system  involves 
different  ways  for  people  to  save  and  share  the  kinds  of  knowledge  described  above.  For  instance,  we 
are  currently  experimenting  with  linking  Object  Lens  to  a  remote  database  server  that  contains  large 
shared  relational  databases.  This  work  is  still  at  an  early  stage,  but  it  is  clear  that  the  usefulness  of 
Object  Lens  will  be  significantly  enhanced  if  it  includes  access  to  shared  databases.  In  the  current 
version  of  Object  Lens,  we  have  preliminary  solutions  to  the  problems  of  saving  and  sharing 
knowledge  that  meet  some,  but  not  all,  of  the  needs  p>eople  will  have  in  this  area. 

3.9.1  Saving  knowUdge.  Users  can  save  an  object  (or  a  collection  of  objects  in  a  folder)  at  any 
time  by  f>erforming  the  Save  action  on  the  object  (or  the  folder).  This  action  uses  the  file  package 
commands  from  the  underlying  Loops  and  Lisp  systems  to  store  the  objects  in  permanent  files  in  a 
form  that  can  be  reloaded  at  any  time.  There  is  also  a  "Save"  action  on  the  main  Object  Lens  icon  that 
saves  all  the  instances  in  the  workstation. 
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The  potential  disadvantages  of  this  approach  to  saving  knowledge  are  that  (1)  it  requires  explicit  user 
actions  to  save  objects  to  permanent  storage  and  (2)  it  requires  all  knowledge  used  by  the  system  to  be 
loaded  onto  the  local  workstation.  Sharing  remote  databases  will,  of  course,  help  solve  these  problems, 
but  we  expect  that  systems  like  Object  Lens  can  be  of  value  even  without  shared  databases.  For 
example,  many  users  are  already  accustomed  to  explicitly  saving  their  work  in  applications  such  as 
word  processing,  and  even  this  task  can  be  simplified  by  creating  agents  to  run  periodically  (e.g.,  every 
night)  and  do  automatic  backups  of  selected  objects. 

3.9.2  Sharing  knowledge  by  sending  messages.  There  are  two  ways  users  of  Object  Lens  can 
share  objects  with  each  other:  (1)  by  sending  messages,  and  (2)  by  transferring  files.  In  this 
subsection,  we  discuss  sending  messages;  Ln  the  next,  we  discuss  transferring  files.  When  an  Object 
Lens  user  sends  a  message,  the  message  object  is  converted  into  text  and  sent  via  the  existing  mail 
system.  Any  connected  electronic  mail  users  can  receive  and  read  this  textual  message.  When  an 
Object  Lens  user  receives  the  message,  it  is  added  as  a  new  object  in  the  receiver's  knowledge  base. 

When  a  user  sends  a  message  containing  an  embedded  object  that  is  expsinded  (as  in  Figure  2),  the 
embedded  object  is  converted  into  (indented)  text  in  the  message  in  a  form  that  (a)  can  be  easily  read 
by  any  receivers  who  are  not  using  Object  Lens  and  (b)  is  reconverted  into  another  embedded  object 
when  it  is  received  by  Object  Lens  users.  When  a  user  sends  a  message  containing  embedded  objects 
that  are  not  expanded  (e.g.,  that  are  shown  only  as  link  icons),  the  names  of  the  objects  are  included  in 
the  message  in  place  of  the  link  icons,  but  these  names  are  not  resolved  back  into  link  icons  at  the 
receiver's  end. 

One  intriguing  research  direction  here  involves  how  to  communicate  embedded  objects  in  such  a  way 
that  they  can  be  resolved  into  pre-existing  objects  at  the  receiver's  end.  For  example,  if  the  sender's 
message  contains  a  link  to  a  person  object,  it  would  be  nice  for  the  receiver's  system  to  be  able  to 
automatically  resolve  this  link  into  the  receiver's  object  representing  the  same  person. 

3.9.3  Sharing  knowledge  by  transfering  files.  The  second  way  for  users  to  share  objects  is  by 
transferring  files.  As  described  above,  it  is  easy  for  users  to  store  on  a  file  server  the  current  state  of  a 
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set  of  objects.  Other  users  can  then  load  these  files  to  create  (or  update)  the  objects  in  their  own 
workstations  Saving  and  loading  these  files  can  often  be  done  automatically.  For  example,  we  expect 
that  a  common  way  for  users  to  keep  current  versions  of  shared  information  such  as  names,  addresses, 
and  job  titles  of  people  in  their  organization  will  be  to  have  someone  maintain  the  official  version  of 
this  irJbrmation  and  periodically  distribute  updates  to  other  users  in  the  organization.  Distributing 
these  updates  could  be  done  in  several  ways:  (1)  the  "maintainer"  could  have  automatic  agents  that 
periodically  store  the  current  versions  on  a  file  server  and  the  other  users  could  have  automatic  agents 
that  periodically  load  the  most  recent  versions,  or  (2)  the  maintainer  could  explicitly  send  out 
messages  announcing  the  availability  of  files  containing  updated  objects  and  the  other  users  could 
have  agents  that  automatically  load  the  files  announced  in  such  messages  (e.g.,  a  rule  might  load  all 
files  specified  in  "Official  file  update"  messages  from  the  ofTicial  maintainer). 

One  potential  problem  with  this  approach  is  that  any  changes  the  users  have  made  to  their  local  copies 
of  objects  (eg.,  any  notes  they  had  added  in  the  Comments  field)  will  be  lost  when  a  new  version  of  the 
object  is  loaded.  To  help  solve  this  problem,  we  are  currently  investigating  more  specialized  updating 
actions  for  agents  to  use.  With  this  approach,  the  official  maintainer  will  be  able  to  distribute  update 
messages  that  specify  changes  in  particular  fields  of  particular  objects.  Users  can  then  set  up  agents 
that  make  these  updates  automatically  under  most  conditions,  but  under  certain  conditions  the  user 
might  be  notified  before  the  update  is  made  (e.g.,  if  the  field  about  to  be  modified  has  previously  been 
changed  by  the  user).  In  some  cases,  the  user  might  want  to  have  the  change  made  automatically  but 
also  be  notified  (e.g.,  if  someone  in  the  user's  group  is  changing  phone  numbers). 

4.  OTHER  APPLICATIONS 

In  this  section,  we  will  give  more  examples  of  how  the  above  features  can  be  combined  to  create  a 
variety  of  cooperative  work  applications. 
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4.1  Task  tracking 

One  frequently  mentioned  capability  for  coop>erative  work  applications  is  the  ability  to  keep  track  of 
the  tasks  people  are  supposed  f-o  do  (e.g.,  Winograd  &  Flores,  1986,  Sluirer  &  Cashman,  1984).  For 
instance,  such  systems  can  help  answer  questions  like:  What  tasks  have  other  people  requested  me  to 
do?  Are  any  of  these  tasks  overdue?  What  tasks  have  I  requested  other  people  to  do  for  me? 

It  is  a  straightforward  matter  to  support  capabilities  like  this  in  Object  Lens.  For  instance,  the  system 
already  includes  message  types  for  action  requests  and  commitments.  Even  in  the  Information  Lens, 
it  was  possible  to  automatically  sort  these  messages  into  folders  according  to  who  is  to  perform  the 
task,  which  project  it  involves,  and  so  forth.  In  the  Information  Lens,  however,  the  summary  display  of 
a  folder's  contents  shows  only  the  standard  message  header  fields:  From,  Date,  and  Subject.  To  see 
more  about  the  tasks,  individual  messages  have  to  be  displayed,  one  at  a  time.  In  Object  Lens,  the 
messages  within  a  folder  can  easily  be  summarized  by  displaying  whatever  fields  the  user  chooses. 
For  example,  Figure  8  shows  a  table  display  of  action  request  messages  that  includes  the  action 
deadline. 

4.2  Intelligent  message  sorting:  Engineering  change  notices 

As  we  have  described  in  more  detail  elsewhere  (Malone  et  al,  in  press),  an  intriguing  example  of  a 
cooperative  work  problem  involves  disseminating  information  about  changes  in  product  specifications 
(often  called  "engineering  change  notices")  to  the  appropriate  people  in  an  organization.  It  was 
already  possible  in  the  Information  Lens  to  sort  engineering  change  notices  according  to  the  contents 
of  fields  such  as  Part  Affected,  Type  of  Change,  and  Severity.  In  Object  Lens,  it  is  possible  to  use 
additional  knowledge  to  do  even  more  intelligent  sorting.  For  instance,  Figure  9  shows  a  rule  that 
uses  a  doubly  embedded  description  to  select  all  change  notices  that  involve  parts  for  which  anyone 
reporting  to  a  particular  manager  is  responsible. 
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4.3  Database  retrieval 

There  are  clearly  many  cases  in  both  individual  and  cooperative  work  when  it  is  useful  to  be  able  to 
automatically  retrieve  from  a  database  objects  that  satisfy  certain  conditions.  Object  Lens  provides  a 
simple  way  to  f)erform  database  queries:  Users  can  simply  create  agents  that  scan  the  objects  in  one 
folder  and  insert  links  to  selected  objects  into  another  folder.  The  rules  in  the  agents  specify  the 
criteria  for  selecting  objects. 

For  instance,  suppose  you  wanted  to  find  all  the  technical  staffmembers  who  were  assigned  to  both  the 
project  code-named  "Dragon"  and  the  one  code-named  "Lancelot."  Figure  10  shows  a  rule  that  would 
retrieve  all  such  people.  Instead  of  listing  all  the  technical  job  titles  by  name  ("software  engineer", 
"systems  programmer",  etc.),  the  rule  includes  an  embedded  description  to  determine  whether  a 
particular  job  title  is  on  the  technical,  as  opposed  to  the  managerial  or  administrative,  career  ladder. 

In  addition  to  this  general  interface  for  database  retrieval,  we  have  also  implemented  a  specialized 
feature  in  Object  Lens  for  determining  the  recipients  of  messages.  With  this  feature,  descriptions  (like 
that  shown  in  the  IF  field  of  Figure  10)  can  be  embedded  in  the  To  and  cc  fields  of  a  message.  Then, 
when  the  message  is  sent,  these  descriptions  are  automatically  applied  to  all  the  Person  objects  in  the 
local  knowledge  base  and  the  resulting  people  are  inserted  in  the  To  and  cc  fields.  This  feature  allows 
senders  to  create  distribution  lists  that  are  dynamically  computed  at  message-sending  time  based  on 
the  current  information  about  people  in  their  data  base  (see  Zloof,  1981  for  a  similar  capability). 

4.4  Hypertext 

As  noted  above,  it  is  a  straightforward  matter  to  use  many  of  the  features  of  a  hypertext  system  in 
Object  Lens  (eg.,  Halasz,  Moran,  &  Trigg,  1987;  Garrett,  Smith,  &  Meyrowitz,  1986;  Delisle  & 
Schwartz,  1986).  For  instance,  our  system  currently  contains  an  object  type  called  Text  that  displays 
only  two  fields:  Name  and  Text.  The  Text  field  of  a  Text  object  can  contain  links  to  as  many  other 
objects  as  desired.  For  example.  Figure  11  shows  a  sample  Text  object  that  contains  links  to  people 
and  bibliographic  citations  as  well  as  to  another  Text  object. 
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In  addition  to  the  usual  benefits  of  h>-pertext  systems,  Object  Lens  derives  additional  benefits  from  its 
integration  of  hypertext  with  other  database,  messaging,  and  computational  capabilities.  For 
instajice,  in  order  to  insert  a  link  to  another  node  in  a  hypertext  system,  a  user  must  first  find  the  node 
to  which  the  link  will  be  made.  In  Object  Lens,  the  database  retrieval  capabilities  described  above  can 
be  used  to  automatically  find  objects  (such  as  i>eople  or  bibliographic  citations)  that  satisfy  certain 
criteria.  Then  links  to  these  objects  can  be  inserted  into  the  text.  One  desirable  feature  found  in  some 
hypertext  systems  that  is  not  yet  included  in  Object  Lens  is  the  ability  to  show  and  follow  the  incoming 
links  to  an  object.  We  would  like  to  implement  this  capability  as  another  action  available  on  all 
objects. 

Even  though  the  relationship  between  Object  Lens  and  previous  hypertext  systems  is  not  the  primary 
focus  of  this  paper,  it  is  interesting  to  observe  that  Object  Lens  apf)€ar3  to  have  some  functionality  in 
at  least  four  of  the  seven  areas  that  Halasz  (1987)  listed  as  being  needed  in  the  next  generation  of 
hypermedia  systems  (search  and  query,  computational  engines,  collaborative  work,  and  tailorability). 

5.  CONCLUSION 

In  this  paper,  we  have  described  a  system  called  Object  Lens  that  integrates  facilities  for  hypertext, 
object-oriented  databases,  electronic  messaging,  and  rule-based  agents.  Using  the  basic  primitives 
provided  by  this  system,  we  believe  it  will  be  relatively  easy  to  create  a  wide  variety  of  cooperative 
work  applications.  We  have  shown  several  such  applications  here,  and  an  important  focus  of  our 
ongoing  research  will  be  to  test  the  generality  of  the  framework  further  by  implementing  more 
applications  within  it. 

Object  Lens  is  an  example  of  a  semiformal  system,  a  system  that  represents  knowledge  in  a  way  that 
both  people  and  their  computational  agents  can  process  intelligently.  We  believe  that  much  of  the 
power  and  fiexibility  of  this  system  results  from  its  choice  of  primitives  (semistructured  objects, 
customizable  folders,  and  semiautonomous  agents)  and  from  the  template-based  interfaces  that  make 
these  primitives  both  visible  and  changeable  by  inexperienced  computer  users. 
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Figure  3.   Object  types  are  defined  by  a  set  of  Templates 
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Close 


Cancel 


Add  Link 


Delete 


♦Gtheri 


RULE: 


Name: 
If: 


Alternative  3  for  ActJdn  Deadline 


Tomorrow 
This  week 

A5.3P 

'.'.'he  never 


llf<lf»tll*fT1T1IIf»I 


ACUGN  REQUaSJ 


DatG; 

To: 

From; 

A<:lton  DcBdltne:  Today,  Tomorrov 

Keywords: 

T«xl; 


Then: 


WOVE 


To: 


FOLDEFi; 
Urgent 


Figure  5.   Rules  describe  the  objects  that  will  satisfy  them  and 
specify  what  action  to  perform  on  those  objects. 
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Close 


Name: 
If: 


Cancel        Add  Link        Delete        ♦Others* 


fviESSAGE 


Date; 

la: 

From: 


PERSON 


Name. 

Job  titie:  vies  preaident 

Cllice: 

iGi^phonG  Number: 

Supervisor: 

Projects: 

Keywords: 

Comments: 


cc; 

Keysyords: 
Text: 


Then: 


f^OVE 


To. 


folDER: 
Urgent 


I  I  I  I  I   I   I  I  I  I  I   M  M  t  T  I   I  T  M  I  <  I   I   I  I  I  I   I   I  I   I   I  I  I   I  I   I  I   I   I  I  I  I  I   I   I  I  I   I   I   I   I   I   I  tl 


I  I  I  I  I  I  I  M  I 


Figure  6.   Rules  can  use  embedded  descriptions  to 
create  complex  queries. 
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Close 


FOLDER:  People 


Name 


Cancel 


Show  Next       Delete  Selection 


^Others* 


•Job   title 


Supervisor 


Rov    Keii-rl 
Charier    ijrav 
Marv   Willvams 
K.aren   Fox 
Frank   Menaul 
Li  ia   Hurvitz 
Maurice   Gilman 
Eric    Stavris 
Susan   Menano 


Vice-ores  ident 

Director 

Manaaer 

fiVbfi.b'-.irr 

Software   Enrjineer 

Software   Enoineer 

Sviteriis   Procirainmer 

Manager 

M  ri  fit  1  m  i  t  r  a  1 1 V  e   A  s  s  t 


Robert  Penta 
Rov  Kessel 
Charles  Grav 
Charles  Grav 
Marv  Williams 
Marv  Williams 
Karen  Fox 
Charles  Grav 
Eric  Stavris 


^^T^m  M  M  I  I  I  I  I  M  I 


Close 


FOLDER:  People 


Name 


Cancel 


Show  Next       Delete  Selection  *Others* 


Office 


Telephone  Number 


Rov  Kessel 
Charles  Grav 
Marv  Williams 
Karen  Fox 
Frank,  Menaul 
Lisa  Hurvitz 
Maurice  Gilman 
Eric  Stavris 
Susan  Menano 


t)l2- 
1312- 
014- 
014- 
014- 
014- 
019- 
014- 
019- 


?50 
250 
990 
AlA 
990 
990 
490 
AlA 
490 


57 

C7 


0793 
_  5915 
57-4S21 
57-2219 
57-5315 
57-6174 
557-3430 
"""  6174 


M  I  I  I  I  I  ITT'TTTTTTTTTTTTTTT^'TTTTT^TTTTTT^TTTT^T^^^rm  I  I  I  I  I  I  I 


pm^T»"rTi 


Figures  7  a,b,c.   Users  can  select  which  fields  to  display 
in  tables  that  summarize  a  collection  of  objects. 
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Close 


Cdncel       Zoom  Out       Zoom  In        *Others* 


Superv  isor 


PEP,  iijfj'      1        JCFP.-arj-  I 

Enc    :t.»vrij        1  -usin   }.AtnAr\>i 

CFF  ^  i-.fi'   I  ICFF  -^|^J■  1 


C  E  p.  i  O  r  i' 


H 


c  Eft  i  or  J' 


P  E  P.  i  O  r  f 
Mary  VVillij 


PER  ;Orj- 


pTpToTT       1 


,  ■  ■  ■  ■  ■ .  ■  ..,■■.  .■.■,.■,  ,,,■,■■■■■■■■■■ .  ■■■ ,■,,.,■■■.. ...  ,  ,  ■ ,  , , , , .■ ■■.■.■■.■■■■■  .■■ , ......  ..,. 


Please    select    object    (or    its    link) 


Close  Cancel 

Subject 


FOLDER:  To  do 


I  LP    Visit 
Comments   on   o.aoer 
Can   Daws 
Thesis   i3uestion 
CSCW   paper 


Show  Next       Delete  Selection 

From 


♦Others ♦ 


Elesie   Brown 
Wendv   Mack  a V 
Ele::e   Brown 
■J  1  n  t  a  e   Lee 
David  Rosenblitt 


Action   Dead  1 ine 


15-0ct-83 
15-0ct-88 
15-0ct-83 
25-0ct-33 
12-NOV-S3 


Figure  8.   Tables  can  be  used  to  summarize  selected  fields 
from  Action  Request  messages. 
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Close 


Cancel      Add  Link      Delete       ♦Others* 


If: 

ENG,N£ERiNG  CHANGE  NOJiCE 

Subj€<:t: 
Date; 

From, 

<:<:. 

ignore  Alter; 

Fart  atl^cted; 

PART 

Name, 

Fart  number; 

Subsystem; 

Engineer  responsible; 


FERSON 


Name, 

Job  titie; 

Ollt<:e; 

leiephane  Number; 

Supervisor,  Kevin  Crowston 

Froje<:ts; 

Key\>ords; 

Comments; 


Keyvsords; 
Comments; 


Type  al  <:hange; 
Reason  for  <:hange; 
Se\/enty; 
Key\>ords; 
Des-oription  ol  -change; 


Then: 


MOVE 


la; 


FOlDEF. 

Our   .jrcnip'r   ECrij 


Figure  9.   Rules  can  include  multiple  levels  of  embedded  descriptions 
that  refer  to  linked  objects  throughout  the  knowledge  base. 
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Close         Cancel      Add  Link      Delete      ♦Others* 


Name: 
If: 


PERSON 


Name; 
Job  tttie: 


JOa  HJLE 


Altennatives  for  Career  ladder 


Techfiic-il 

M.3  nog-?  rial 

Adminiitfcitive 


Name: 

Salary  range: 

Exempt /Nart-Gxempt: 

Career  ladder:  Technical 

Keywords: 

Comrrtents: 


OHi<:e: 

Telephone  Number: 

Supervisor: 

Proje<:t3:  Dragon  3.  Lancelot 

Keywords: 

Comments: 


Then: 


copy 


To. 


FOLDER^  I 

Drajon  9,  Lancelot  teennicai  pir.^\4 


Figure  10.   Agents  can  retrieve  all  the  objects  from  a  database  that 
satisfy  certain  criteria. 
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Name:  Camp  David  negotiations 

Text:     At  Camp  David,  President  Sadat  of  Eovpt  i 

■^  '  »i  .  .  Mil. 


FEF,  iON' 


)  agreed  to 


and  Prime  Minister  Begin  of  Israel  i; 

a  plan  that  would  return  the  Sinai  to  complete  Egyptian 

sovereignty  and,  by  demilitarizing  large  areas  would  stil 

assure  Israeli  security  ( 


TTtT     "         ] 

ll£lillliilt»Il2J) .    The  Egyptian  flag 


would  fly  everywhere,  but  Egyptian  tanks  would  be_ 
nowhere  near  Israel.    [From 


B  0  Q 


Q*-    CITATION;! 
nmq  to   Yts         I] 


Figure  11.   Hypertext  documents  can  Include  links,  not  only 
to  other  text  passages,  but  also  to  other  object  types  such  as 
people  and  bibliographic  citations. 
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Date  Due 
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